This is a big change from @slukes work. Rather than use an async promise here, the resolvePassword logic tries to keep everything synchronous when it can. It's only when this.options.password returns a promise that this callback will be invoked in a separate tick.

If this is changed into async logic, there are a few tests that fail because there seems to be an expectation that the connect logic runs the connector which sets this.connecting = true before any other code runs.
e.g., the following test would fail when making resolvePassword async:

  it("connects successfully immediately after end", (done) => {
    const redis = new Redis();
    redis.once("end", async () => {
      await redis.connect();
      done();
    });

    redis.quit();
  });

The connect function (which is called from the constructor) calls into the connector and sets connecting to true on the connector. If that variable is no longer true in the next tick, it rejects the connect request and will trigger a transition into the end state.

However, if connect needs to resolve something else asynchronously, by the time redis.quit runs, the connector may not have run yet. The net effect of this is that the client will first disconnect and then re-connect, because the end-user has no control over the connect.

All of that said, this test could be changed to wait until the client is ready. Would that be breaking behaviour?

  it("connects successfully immediately after end", (done) => {
    const redis = new Redis();
    redis.once("end", async () => {
      await redis.connect();
      done();
    });

    redis.on("ready", () => redis.quit());
  });

This is another change from @slukes work. This allows pipelining and the offline queue to function.

tip: This PR becomes a lot more reviewable when hiding whitespace changes ...